Clean code 最麻煩的地方，是它太容易被講成品味。
有人覺得命名要漂亮一點。有人覺得函式要短一點。有人覺得重複邏輯看了很刺眼。講到最後，很容易變成一種工程潔癖之爭：你喜歡乾淨，我喜歡能跑，大家各退一步。
但 coding agent 進來以後，這個講法有點太軟了。
髒 code 會讓 reviewer 看得痛苦，也會直接變成 agent 的操作成本。Agent 要多翻幾個檔案，多猜幾次邊界，多重讀同一段邏輯，多燒一輪 token，最後還可能交出一個「看起來像改好了」但其實碰錯地方的 patch。
所以我現在比較不想問：「AI 這麼強了，還需要 clean code 嗎？」
比較好的問題是：
這個 repo 讓 agent 花多少力氣，才知道自己到底在改什麼？
先講清楚一點。Clean code 不是魔法。
最近一篇 code-cleanliness 研究做了很有趣的 minimal-pair 實驗。研究者把六組 repository 做成乾淨版和不乾淨版，盡量控制架構、依賴和外部行為，再讓 Claude Code 跑 33 個任務，總共 660 次 trial，用 hidden tests 評估結果。
最值得注意的不是「乾淨 code 讓 agent 成功率暴增」。
因為研究裡沒有看到這件事。
乾淨版並沒有明顯提高 pass rate。這點很重要，不能硬拗成 clean code 會讓模型突然變可靠。Agent 還是可能誤解需求，還是可能漏掉 edge case，還是可能把測試通過誤以為行為正確。
但乾淨版有降低操作 footprint。
研究觀察到 token use 少了 7-8%，file revisits 少了 34%。這聽起來沒有「成功率提升」那麼漂亮，可是對真實團隊反而更接近痛點。
因為 agent 成本不是只看最後有沒有過。
你還要看它為了過那一關，在 repo 裡迷路多久。
很多人聽到 token cost，第一反應是模型帳單。
這當然是成本，但不是最痛的那個。更痛的是被 token cost 代表出來的東西：agent 在不確定的地方來回找路。
它讀一個檔案，發現命名不一致。再讀另一個檔案，發現同一件事被寫了三種版本。它看見 helper，但不確定是不是 legacy。它找到一段 business logic，卻發現真正的例外處理藏在呼叫端。它改了 A，測試紅在 B，於是回頭再掃一遍。
這些行為最後會變成幾種很實際的成本：
所以 clean code 在 agent 時代的價值，不是讓 repo 看起來比較漂亮。
它比較像路標和地圖。
命名一致、邊界清楚、重複邏輯少、函式責任小、測試能說明行為，這些東西不會保證 agent 做對事。但它會減少 agent 花在「理解地形」上的浪費。
人類也一樣。
差別是，人類迷路時可能會去問同事，或憑幾年專案記憶繞過去。Agent 沒有這種社交脈絡。你沒有寫在 repo 裡的東西，它大多只能猜。
而猜，通常不便宜。
我覺得 vibe coding 債務最可怕的地方，不是 bug 變多。
Bug 至少會痛。會有人罵，會有人修，會有 incident，會留下痕跡。
更麻煩的是 code bloat。功能看起來都還能跑，但系統裡多了很多沒人敢動的東西：重複元件、半套 abstraction、一次性 helper、沒人確定還有沒有使用者會走到的頁面、被 agent 補出來但不在產品心智模型裡的邊界條件。
這種債不一定每天爆炸。
它只是讓團隊慢慢失去刪 code 的能力。
最近 Slopfix 被拿來討論，就是因為它把這件事講得很赤裸：有人願意付錢，請工程師和 agent 一起把 AI 生成後膨脹出來的 code 刪掉。這件事最有意思的不是價格，也不是「用 AI 刪 AI code」這個標題。
真正值得看的是流程。
它不是一上來就叫 agent 大掃除。它先盤點 screens 和 endpoints，把目前還要保留的行為做成 inventory，再把這份 inventory 變成 regression checklist。接著才談刪除、lint、CI、agent instructions 和 guardrails。
這才是重點。
刪 code 不是勇氣問題，是可驗證性問題。
如果你不知道系統現在有哪些入口、哪些畫面、哪些外部合約、哪些行為不能破，你就不能安全刪。你只能憑感覺猜「這應該沒人在用」。以前這種猜法就已經危險，agent 進來後更危險，因為它可以很快幫你刪很多東西，也可以很快幫你把錯誤整理得像合理重構。
乾淨的 codebase 比較容易加功能。
它也比較容易刪。
Clean code 最容易失敗的推廣方式，是把它講成品德。
要有工匠精神。要寫給人看。要保持專案整潔。這些話不算錯，但在專案壓力裡很容易被打敗。產品要上線，bug 要修，老闆要 demo，技術債先欠一下。
Agent 時代比較好的講法，是把 clean code 改成 operating rule。
不要說「命名要清楚」。
要說：agent PR 如果改了 domain term，必須說明它是 readability rename 還是概念變更。user、member、account、profile 不能被當成同義詞亂換。
不要說「不要重複邏輯」。
要說：同一個 business rule 如果被 agent 複製到第二個地方，reviewer 要退回，除非 PR 明確說明為什麼不能共用，並補上防止兩邊 drift 的測試或註解。
不要說「函式不要太複雜」。
要說：高 cognitive complexity 區域不給 agent 自動大改。先要求它列出分支、外部副作用和測試缺口，再決定要拆小任務，還是由人類先整理。
不要說「刪 code 要小心」。
要說：cleanup 任務必須先交 inventory。保留哪些 endpoints、screens、CLI commands、API contracts、feature flags、migration path。沒有 inventory，就不能讓 agent 直接刪。
這些規則聽起來比較沒情懷。
但它們比較像工程。
如果一個團隊真的要讓 agent 處理維護和 cleanup，我會要求每個比較有風險的 agent PR 交幾樣東西。不是表格越長越好，而是 reviewer 需要看見足夠的脈絡，不要只收到一包 diff。
第一，變更摘要。不要寫「refactor code for clarity」這種廢話，要具體說明它改了哪個行為、哪個模組、哪個邊界。
第二，刪除理由。刪掉的 code 為什麼可以刪？是完全未使用、被新路徑取代、功能下線，還是重複邏輯合併？
第三，保留行為清單。這次 cleanup 後，哪些使用者可見行為必須不變？有哪些 API response、UI state、錯誤訊息、權限流程不能動？
第四，驗證證據。跑了哪些測試，哪些沒跑，哪些只能人工驗。不要只寫「tests passed」。那太便宜了。
第五，風險區域。Agent 覺得哪裡最容易錯？哪些檔案看起來相關但它刻意沒碰？如果它說完全沒有不確定，我反而會緊張。
第六，防止長回來的 guardrail。Lint、static analysis、dead code detection、duplicated logic check、CI blocking rule、review checklist、agent instruction file，至少要有一個讓同樣問題不要下週又長回來。
目的不是讓流程變官僚，而是讓 reviewer 不必從一包漂亮 diff 裡重新猜故事。
Agent 很適合做整理型工作。
也正因為適合，所以危險。
它可以很快改命名、搬檔案、抽 helper、刪 dead code、補測試、整理 import。這些改動單看都不大，但累積起來會改變 repo 的形狀。Repo 形狀一變，下一次 agent 讀到的地圖也會變。
所以我會把一部分 clean code 規則移到 CI，而不是只靠 reviewer 意志力。
例如：
這些規則不會讓 agent 完全安全。
但它們會把一部分「請你小心」變成「你過不了這條線」。
對 agent 來說，後者通常比較有用。
這裡也要補一個 nuance。
我不喜歡那種太快下結論的說法：agent 進來以後，新人工程師就沒有練習場了。
這個擔心可以討論，但不能只靠想像。一篇 2026 年 7 月的 OSS 研究觀察到，在它研究的 established OSS projects 裡，agent adoption 沒有顯著造成 newcomer participation 下降。可是同時，它也看到 code complexity 有 modest increase。
這個結果反而比較值得想。
也許短期內，新人沒有立刻消失。Issue 還在，PR 還在，大家還是可以參與。真正慢慢變難的是另一件事：系統變得更不好教、更不好 review、更不好解釋。
新人最需要的不是一個永遠乾淨的童話 repo。
新人需要的是可讀的邊界、可追的變更、可理解的錯誤、可問的問題。Reviewer 也一樣。當 agent 把 complexity 一點一點堆上去，老手可能還能靠經驗撐住，新人和 reviewer 會先感覺到壓力。
所以 clean code 在這裡不是懷舊。
它是團隊把知識留在系統裡的方法。
現在很多 agent control 的討論會走向安全、監控、權限、shutdown。這方向是對的。當 agent 可以碰更多檔案、跑更多命令、甚至開始替你規劃多步任務，團隊不可能只靠一句「human in the loop」就放心。
但對一般工程團隊來說，最日常的控制不是科幻級的 rogue agent 防線。
是便宜的回復路徑。
它改錯了，你能不能看懂它改哪裡？
它刪多了，你能不能知道哪個行為被破壞？
它生成太多，你能不能安全修剪？
它做了一個看似合理的 abstraction，你能不能在三週後撤回？
Clean code、測試、inventory、CI、log、review checklist，這些東西都不是新概念。只是 agent 把它們的重要性往前推了一格。
以前你可以說：「這段雖然亂，但大家都知道不要碰。」
Agent 不知道。
以前你可以說：「這裡先欠著，之後有人會整理。」
Agent 可能會在欠著的地方繼續加東西。
以前你可以說：「這個命名有點怪，但資深同事懂。」
Agent 不懂那個眼神。
所以回到最開始。
Clean code 在 agent 時代不是品味問題。
也不是要把 repo 修成某種展示品。真實專案永遠有歷史包袱，有趕時間留下的折衷，有還沒拆完的 migration，有你看了會嘆氣但今天不能動的老模組。
重點不是假裝這些不存在。
重點是讓人和機器在同一個系統裡，還能做便宜、可驗證、可回復的改動。
乾淨的邊界讓 agent 少迷路。
清楚的命名讓 reviewer 少猜。
好的測試讓刪除少一點賭運氣。
CI guardrail 讓同樣的膨脹不要一直長回來。
Inventory 讓 cleanup 從勇氣變成流程。
這些事情以前就重要。只是現在它們不只給人看，也開始變成 agent work 的基礎設施。
Agent 越多，clean code 越不該被當成潔癖。
它是你願不願意為未來每一次修改，先把路標立好的問題。
ryanvale
看影片追技術